軟體開發專案中常見的爭論在於花時間提升軟體品質，還是專注於釋出更有價值的功能。通常交付功能的壓力主導討論，導致許多開發人員抱怨他們沒有時間處理架構和程式碼品質。這場爭論基於一個假設，即提升品質也會增加成本，這是我們常見的經驗。但反直覺的事實是，內部軟體品質消除了減緩開發新功能的累贅，進而降低了軟體增強的成本。

理想狀態下，產品模式組織由鬆散結合的自主團隊組成，這些團隊能快速回應明確和不明確的使用者需求。然而，有時會出現需要跨多個團隊協調的回應機會。如果沒有有效管理，結果將會造成收入損失、客戶不滿意和團隊產能浪費。我們將回應這些機會的組織計畫稱為程式。在本文中，我們將透過一個失敗程式的範例，分享我們在產品模式組織中管理程式的經驗。

管理階層熱愛他們的指標。他們的思考模式大概像這樣：「我們需要一個數字來衡量我們的表現。數字能讓大家專注，並幫助我們衡量成功。」儘管出發點良好，但數字管理法卻會直覺地導致有問題的行為，並最終偏離更廣泛的專案和組織目標。指標本身並非壞事，只是經常被不當使用。本文說明了管理階層傳統使用指標所造成的許多問題，並提供了一個解決這些功能障礙的替代方案。

開端是專案開始時執行的一項活動，用於召集相關人員，並為正在進行的工作設定共同的方向和工作方式。精實開端是一種重點式開端，可以在一週內完成。在此期間，我們了解產品的主要功能和客戶，並建立一個畫布來制定最小可行性產品的特徵。

對齊地圖是一種組織資訊散熱器，有助於將正在進行的工作與業務成果視覺化。這項工作可能是常規功能新增，或技術工作，例如重新建構、償還技術債務或改善建置和部署管道。團隊成員使用對齊地圖來了解他們的日常工作旨在改善哪些業務成果。業務和 IT 贊助者使用它們來了解正在進行的工作如何與他們關心的業務成果相關。

我們看到許多關於軟體流程、設計實務等充滿情緒的討論。其中許多論點無法解決，因為軟體產業缺乏衡量軟體開發效能某些基本要素的能力。特別是，我們沒有合理衡量生產力的方法。

持續流動是一種排程工作的做法，通常與敏捷軟體開發相關。團隊將軟體功能分解成 使用者故事。接著將這些故事優先順序化成一個粗略的清單。然後團隊選取一些使用者故事並開始處理，完成一個後，再從清單中選取下一個。

在 DesignStaminaHypothesis 中，設計回報線是指在該線以下的功能數量，可以權衡設計品質和上市時間。

技術負債 是個非常有用的概念，但它引發了一個問題：你該如何衡量它？遺憾的是，技術負債不像財務負債，所以很難判斷你負債多少（儘管我們最近在衡量財務負債方面似乎遇到了些麻煩）。

你無法把十磅的屎塞進五磅的袋子裡

-- 任何嘗試過的人

當 Kent 和我撰寫《規劃極限程式設計》時，我們加入了這句異想天開的引言，以幫助了解規劃的精髓。

許多人相信你無法在敏捷專案中使用固定價格合約。由於敏捷流程的重點在於你無法預測未來，這並非不合理的假設。然而，這並不表示你無法提出一個敏捷的固定價格合約，這實際上表示你無法提出一個固定範圍的合約。

許多公司喜歡撰寫固定範圍和價格的合約，因為他們認為這樣可以降低風險。這種說法表示他們的財務義務固定在交易價格上。如果他們沒有獲得滿意的軟體，那麼他們就不必付費。

一個常見的問題是大型專案是否可以使用敏捷技術來執行。畢竟，許多敏捷方法都是針對較小的專案設計的，而他們所抗拒的重量級想法在較大的專案中更為需要。

在我最近的客戶參與中，我預見無伺服器架構是一個完美的契合。然而，採用無伺服器架構的想法並未受到我們客戶的歡迎，因為他們擔心供應商鎖定。對於零售商來說，這是一個有趣的時刻，因為留在 AWS 中可能意味著亞馬遜作為另一家零售業務將獲得競爭優勢。由於不支援競爭對手的想法，我的客戶有興趣確保我們選擇的解決方案可以完全移植到其他雲端供應商。

軟體的優點之一是人們似乎想要它，而且想要得很快。組織通常會要求團隊加快軟體的生產，而且時不時地，組織會尋求以真正展現其承諾的方式提供協助 - 透過花錢增加團隊成員。

我第一次接觸敏捷軟體開發是在極限編程的黎明時期與 Kent Beck 合作。令我印象深刻的事情之一是我們規劃的方式。這包括一種估算方法，既輕量又比我以前見過的更有效。現在已經過去了十多年，現在經驗豐富的敏捷主義者之間對於估算是否值得進行，甚至是否具有積極的危害性，存在爭論。我認為要回答這個問題，我們必須了解估算將用於什麼目的。

敏捷開發的一個關鍵特性是找出如何讓系統在僅有少數功能的情況下上線。我們開發軟體是為了提供商業價值，我們上線的速度越快，就能越快獲得至少部分的商業價值。

敏捷開發的基本原則之一是需求變更不僅是預期的，而且是受歡迎的。當外部公司（例如 Thoughtworks）為客戶工作時，這會帶來一個特殊的挑戰。許多客戶希望有固定價格的安排，這實際上是固定範圍，因為他們看到了固定範圍的幻象。但是固定範圍合約與敏捷開發完全相悖，那麼像我們這樣的公司該怎麼辦？

使用時間盒迭代的一個常見方法是將儘可能多的使用者故事分配到每個迭代，以最大化相關人員的利用率。鬆弛是故意留出未分配給故事的時間，將該時間用於未計畫的工作。雖然這看似效率低下，但通常會顯著提升團隊的生產力。

最近我聽到了幾個問題，關於為使用極限程式規劃方法的多個團隊提出一個標準故事點機制。希望是讓多個團隊都使用等效的故事點，因此一個團隊的三個故事點工作量與另一個團隊相同。

我認為嘗試提出這個方法充其量是價值有限，最糟的情況是危險的。

如果你正在使用 XP 風格的規劃，你需要從開發人員那裡取得快速共識的估計。拋出估計可以讓你快速得知開發人員對估計是否有類似的看法（這樣你就可以記錄下來並繼續進行），或者是否有分歧（這時你需要更詳細地討論使用者故事）。

時間盒迭代是將專案工作劃分並排程的一種方式，特別是與敏捷軟體專案相關。團隊將軟體的明顯功能分解成使用者故事，並將時間分解成固定期間（例如一週），稱為迭代。接著他們透過將故事分配到迭代中來排程故事。故事會被粗略估計，以便團隊可以找出一個迭代中可以容納多少個故事。

速度是一個有助於校準計畫的概念，它將廣泛的努力陳述與經過時間聯繫起來。速度是團隊（或個人，如果是個人速度）在一段時間內完成多少工作的陳述。通常你應該透過衡量過去期間完成多少工作來確定速度，遵循昨日天氣的原則。一個典型的方法是將過去三個時間期間的速度平均，以確定未來時間期間的速度。速度最初是作為極限編程的一部分形成的，但後來已經廣泛傳播，現在被廣泛用於各種敏捷軟體開發中。

Yagni 最初是一個縮寫，代表「你不需要它」。它是一個來自極限編程的咒語，通常在敏捷軟體團隊中普遍使用。它是一個陳述，表示我們假設我們的軟體在未來需要的一些功能不應該現在就建構，因為「你不需要它」。

這是個原則，表示你今天會完成與昨天一樣多的工作。在反覆運算專案中，表示你應該計畫在這次反覆運算中完成與上次反覆運算一樣多的工作。這個術語來自極限程式設計社群。